1. Field of the Invention
This invention relates to a method and apparatus for managing thread execution in a multithreaded application. More particularly, it relates to a method and apparatus for controlling the suspension and resumption of individual threads using standard POSIX mechanisms.
2. Description of the Related Art
Multithreaded applications are a well-known feature of modern computer systems, especially systems using UNIX-based operating systems. Multithreaded applications have multiple threads of execution, each of which may be performing an individual task relatively independently of other threads of the same application. For example, individual threads of a server process may be processing units of work received from different clients.
Signals are one of the means such processes and threads use to communicate with one another. At the process level, signals are a well-known means of interprocess communication (IPC), being described, for example, at pages 43–53 of W. R. Stevens, UNIX Network Programming (1990), incorporated herein by reference. As described in that reference, a signal is a notification to a process that an event has occurred. Signals may initiate such actions as terminating execution (e.g., SIGKILL, SIGTERM), suspending execution (SIGSTOP) or resuming execution of a suspended process (SIGCONT). To send a signal to another process, a process uses the services of the operating system kernel to generate a signal and direct it to the intended recipient. Thus, in the UNIX system defined by the UNIX System Services (USS) component of the IBM z/OS operating system, to send a signal to a process, a process may issue a kill( ) service request to the kernel specifying the target process and the signal to be sent. This is described in such references as the IBM publications z/OS UNIX System Services Programming: Assembler Callable Services Reference, SA22-7803-02 (Mar. 2002), and z/OS C/C++ Run-Time Library Reference, SA22-7821-02 (Mar. 2002), both incorporated herein by reference.
The action taken by the target process upon receiving the signal depends on the signal in question, as indicated above. In general, a process receiving a signal can do one of several things. It can “catch” the signal by passing control to a routine known as a signal handler to perform a specified function as determined by the target process. Alternatively, the target process can simply ignore the received signal, unless it is a signal such as SIGKILL or SIGSTOP that cannot be ignored. Finally, the target process can allow a default action to occur, such as process termination.
Signals may be sent not only between processes, but between different threads of a single process as well. Thus, in the UNIX System Services component of the IBM Z/OS operating system, to send a signal to a particular thread of a process, an originating thread of the same process may issue a pthread_kill( ) service request to the kernel specifying the target thread and the signal to be sent. Here too, the action taken by the target thread depends on the particular signal received.
With this background discussion of threads and signals, we turn to the problem addressed by the present invention. In conventional multithreaded UNIX applications, users are limited in how they can safely stop an individual thread. Current POSIX semantics allow for only an entire process (all threads) to be stopped via a SIGSTOP, SIGTTOU, SIGTTIN, or SIGTSTP signal. This is true even if the “stop” signal is directed at an individual thread via the pthread_kill( ) service. Likewise, the SIGCONT signal will continue all threads in a multithreaded stopped process. Neither of these existing POSIX signal mechanisms allows multithreaded applications to stop and start individual threads.
There are existing mechanisms for managing the execution of an individual task or thread. In UNIX systems, for example, there are services that allow threads to serialize with each other, condition variable and mutex services being probably the most widely used. However, these services require cooperative logic to be in place on the target thread.